The present invention relates to forms, and more specifically, to multiple computerized forms that must operate together to collect data.
The term “document” as used in computer based and produced documents is a convenient metaphor for representing an instance of a form application because it allows the end-user to save, email and digitally sign a complete digital representation of their interactions with the form application and the full context of those interactions. The document is also a convenient metaphor for forms application developers as it gives them a single digital asset that can be routed through a business process, encapsulate the full user experience definition for a rich interactive application, and contain all user input, attachments and digital signatures related to a business process transaction. Thus, it is also easy to offer an offline or disconnected form fill experience to end-users.
However, many business processes require a user to interact with more than one related form. For example, an insurance claim, loan agreement, grant proposal or tax form may consist of a primary form to collect the root data of the transaction as well as numerous additional forms that may conditionally need to be filled out depending on data supplied earlier in the fill experience. There are two solutions to this problem currently in practice. The first is to construct a web application from the collection of forms. The disadvantage of this approach is that it loses the many benefits of a document-centric architecture. The application is no longer expressed as a single document, so the user cannot have an offline or disconnected fill experience. That is, the user is no longer able to locally save a document representing the whole insurance policy, loan agreement, grant proposal or tax filing. If the user tries to email the form they are working on to someone else for collaboration, the context of that form within the web application is either lost or very difficult for the application to maintain. Further, a digital signature on a form in the application protects only that form and not necessarily the full transaction represented by the web application logic. Finally, having to involve server programmers to code web application logic is diametric to the simplification theme at the heart of declarative, document-centric electronic forms technology. It is therefore preferable to meet the functional requirements of multiple form applications by extending the capabilities of the electronic forms system.
The second solution is to cram the logical components of the multiple forms into a single form. In principle, this preserves the document-centric benefits of the web application, but in practice there are consequences for run-time performance, design-time understandability, maintainability and collaborative capability. At run-time, the single document takes much longer to start up and consumes much more memory to represent the run-time structures. The performance of interactional operations degrades because the single document is maintaining a larger, global run-time system of data structures for all logical components, rather than being narrowly focused on the logical components that are applicable to the user experience.